| Oracle® Enterprise Manager Cloud Control Security Guide 12c Release 3 (12.1.0.3) Part Number E36415-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Cloud Control Security Guide 12c Release 3 (12.1.0.3) Part Number E36415-01 |
|
|
PDF · Mobi · ePub |
Securing your Oracle Enterprise Manager deployment involves securing all layers of the stack starting with the underlying operating system (OS) on which the OMS and Repository reside all the way up to the Enterprise Manager components themselves. These recommendations will increase overall security as well as prevent certain DoS attacks.
Harden the machines themselves by removing all unsecure services such as rsh, rlogin, telnet, and rexec on Linux platform (for the list of unsecure services and how to remove them on different platforms, please refer to the CIS benchmarks). It is also recommended to stop non-essential services, this minimizes the 'attack footprint' of the host and reduces resource consumption by services that are not required, freeing up system resources to deliver the best performance from the OMS.
Restrict OS access by supporting only indirect or impersonation-based access to all Oracle Homes by using utilities such as sudo or PowerBroker. Protect the WebLogic Server Home directory, especially the domain directory which contains configuration files, security files, log files and other Java EE resources for the WebLogic domain. Grant only one OS user who runs WebLogic Server the access privilege to the directory.
Ensure that all the Oracle Homes are patched with the latest CPU (Critical Patch Update). This is a recommended best practice for securing the Oracle Management Service, Repository, Agents and managed targets. Setup your My Oracle Support credentials to detect new Security Alerts and CPUs from the Patch Advisor. With the default Security Recommendations for Oracle Products compliance standard, when a target is missing the latest Security patches, a compliance standard violation will be triggered. In addition, the Secure Configuration for Host should be associated to the hosts of the OMS and Repository. There are additional compliance standards for Database and WLS that can be applied depending on your level of security. Review the Oracle Enterprise Manager Cloud Control Administrator's Guide section on Compliance for more information on available compliance standards and how to associate targets.
The OMS runs on top of the Oracle WebLogic Server. Most of the best practices for securing Oracle WebLogic Server are applicable for securing the OMS as well. Refer to the Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server section Securing Oracle WebLogic Server for additional information.
Ensure that the OMS, Repository and Agent are monitored for filesystem space. The OMS writes a lot of information to log and trace files, and proper space needs to be available for successful operation and troubleshooting. The Agent also relies on filesystem space for log and trace files as well as collecting target metrics.
Best Practices for Securing the Infrastructure and Operating System
Remove unsecure services and stop non-essential services on all infrastructure components
Restrict OS access and protect critical files and directories
Apply latest OS security patches
Adhere to security Compliance Standards and apply latest Oracle CPU patches to all components (OMS, Repository and Agent)
Monitor filesystem space for OMS, Repository and Agent
In addition to the above recommendations, steps are necessary to secure the Oracle Management Repository. Since the Oracle Management Repository resides within an Oracle database, a number of the best practices for securing the Oracle database itself are applicable to securing the Repository as well. For best practices on Oracle database security, please refer to the Oracle Database Security Checklist.
The above document also covers certain Operating System level steps that need to be performed to secure the database. Following are additional recommendations to be implemented in the Enterprise Manager deployment.
Enable Advanced Security Option (ASO) between the OMS and Repository to ensure that the data between the OMS and Repository is secure both from confidentiality and integrity standpoints. In addition to the ASO configuration required on the Repository database, you will need to configure the OMS and Agent to connect to a secure Repository database. The detailed instructions for implementing ASO for Enterprise Manager can be found in the Enterprise Manager Security section of the Oracle Enterprise Manager Cloud Control Administrator's Guide.
Please refer to the Oracle Database Advanced Security Administrator's Guide to obtain detailed information about ASO.
Restrict network access to the host on which the Repository resides by putting the repository database behind a firewall and checking network IP addresses. The Listener should be configured to accept requests only from OMS nodes by adding the following parameters into TNS_ADMIN/protocol.ora file:
tcp.validnode_checking =YES
tcp.excluded_nodes = (list of IP addresses)
tcp.invited_nodes = (list of IP addresses), list all OMS nodes here)
The first parameter turns on the feature whereas the latter parameters respectively deny and allow specific client IP addresses from making connections to the Oracle listener. Please refer to the Secure the Network Connection section of the Oracle Database Security Guide for more information.
Audit all SYS (schema) operations at the database level by setting AUDIT_SYS_OPERATIONS = TRUE.
Use the operating system syslog audit trail to minimize the risk that a privileged user, such as a database administrator, can modify or delete audit records stored in an operation system trail if the database version of Repository is 10gR2 or after.
For 10gR2 DB, refer to the Auditing documentation to obtain more information about syslog audit trail.
For 11g DB, set AUDIT_SYS_LEVEL initialization parameter appropriately to use syslog audit trail. Refer to the 11g documentation for details.
Users should log in to the Console with their own individual accounts, and not use the SYSMAN user. SYSMAN is the schema owner and is more privileged than Enterprise Manager Super Administrators. Multiple users should be granted Super Administrator to reduce the need for SYSMAN access. One strong reason for creating multiple Super Administrator accounts is to ensure one user maintains account access in case another user becomes locked out by a dictionary/brute force attack. The Super Administrator privilege should be limited to users who truly need all the permissions that Super Administrator gives them.
In some cases, you may wish to prevent SYSMAN from logging into the console by executing the following SQL statement on the Repository database as the SYSMAN user:
UPDATE MGMT_CREATED_USERS SET SYSTEM_USER='-1' WHERE user_name='SYSMAN'
After disabling SYSMAN from logging into console, you can enable it by executing:
UPDATE MGMT_CREATED_USERS SET SYSTEM_USER='1' WHERE user_name='SYSMAN'
Use password profiles to enforce the password control of Enterprise Manager Administrators while Repository-based authentication is used. There is an out-of-box password profile MGMT_ADMIN_USER_PROFILE with the following parameter settings for Enterprise Manager Administrators:
FAILED_LOGIN_ATTEMPTS=10
PASSWORD_LIFE_TIME=180
PASSWORD_REUSE_TIME=UNLIMITED
PASSWORD_REUSE_MAX=UNLIMITED
PASSWORD_LOCK_TIME=1
PASSWORD_GRACE_TIME=7
PASSWORD_VERIFY_FUNCTION=MGMT_PASS_VERIFY
The out-of-box password verification function MGMT_PASS_VERIFY will ensure that the password cannot be same as username, its minimum length is 8, and it must have at least one alphabet, digit and punctuation character. You can create customized password profiles with different values to meet your special requirements, for example, a new password verification function to meet a stricter password complexity requirement.
Change SYSMAN and MGMT_VIEW users' password on a regular basis using only the method documented in the Security section of the Oracle Enterprise Manager Cloud Control Administrator's Guide. The documented command (update_db_password()) helps you change the SYSMAN related passwords in the OMS and in the repository database. If you do not execute this command properly, the OMS may fail to start due to inconsistent passwords for one of the many accounts. You will be prompted for the old and new SYSMAN passwords.
When changing the MGMT_VIEW password, you can select “-auto_generate” to generate a random password that no one will know. The MGMT_VIEW password is used only by the Reporting system and should not be used for login, therefore the auto_generate flag can ensure the password is not known.
To avoid the service interruption due to the lockout of internal users, SYSMAN and MGMT_VIEW users are associated with MGMT_INTERNAL_USER_PROFILE upon install. The password parameters are all set to UNLIMITED. In addition, to avoid sessions hanging or taking a long time due to resource consumption limit, MGMT_INTERNAL_USER_PROFILE's kernel parameters are set to default, which is unlimited as well.
The Encryption Key is the master key that is used to encrypt/decrypt sensitive data, such as passwords and preferred credentials, stored in the Repository. The key itself is originally stored in the Repository and removed automatically once the installation is done. It only needs to be in the Repository during an upgrade. By storing the key separately from the Enterprise Manager schema, we ensure that the sensitive data such as Preferred Credentials remain inaccessible to the schema owner and other SYSDBA users (privileged users who can perform maintenance tasks on the database). Keeping the key outside of the Enterprise Manager schema will ensure that sensitive data remain inaccessible while Repository backups are accessed. Further, the Enterprise Manager schema owner (SYSMAN) should not have access to the OMS Oracle Homes to prevent reading or overwriting the emkey. See the Oracle Enterprise Manager Cloud Control Administrator's Guide for more detailed information about Enterprise Manager's Cryptographic Support and the emkey. Follow the process outlined below to secure the encryption key.
Backup the encryption key to a file by running the following command and keep the encryption file on a separate machine securely, restrict access to only the OMS software owner. If the encryption key is lost or corrupted, the encrypted data in the repository is unusable.
$ emctl config emkey –copy_to_file_from_credstore –emkey_file emkey.ora
While the encryption key is required to be in the Repository for some operations such as Enterprise Manager patches and upgrades, if the operation does not automatically copy the emkey back to Repository (or remove it from the Repository afterwards), please copy it back to the Repository and after the operation remove it from the Repository by following the procedure below:
$ emctl config emkey –copy_to_repos You will be prompted for SYSMAN password
Remove the key from the Repository once the operation is done.
$ emctl config emkey –remove_from_repos
Best Practices for Securing the Oracle Management Repository
Enable Advanced Security Option on the Repository database and configure OMS and Agent
Restrict network access to known targets
Grant Super Administrator privilege to select administrators and do not log in with SYSMAN account
Enable strong password profiles and change application related account passwords regularly
Secure and backup the encryption key
For better security during agent installation, agents should be deployed using Enterprise Manager Enterprise Manager's Agent Deploy which uses the secure SSH protocol. When manually deploying Agents, to protect against the possibility of users installing unauthorized agents, use one-time registration passwords that have a reasonable expiry date instead of persistent registration passwords. Registration passwords can be created in the Console or by using the emctl secure setpwd command.
Install the agent as a separate user from OMS installation and support only impersonation based access to this account such as sudo or PowerBroker post installation to prevent unauthorized changes.
Best Practices for Securing the Oracle Management Agent
Utilize Enterprise Manager Agent Deployment method for agent installations.
Use one-time registration passwords with expiry dates
Install agent as a separate user from OMS or Targets
There are several ways to secure the communication between OMS and agent, including firewalls, the OMS secure-lock feature, enabling TLSv1, enabling strong cipher suites and certificates. The following section looks at these in more detail.
Enterprise Manager uses the industry-standard Internet Control Message Protocol (ICMP) echo request to check status of target host machines if the agent has not uploaded or responded in a timely fashion or at expected intervals. If ICMP is disabled, the target will appear to be down. Firewall should be configured to allow ICMP to prevent false down target alerts.
A Beacon is a target that allows the Management Agent to remotely monitor services. A Beacon can monitor one or more services at any point in time. ICMP and User Datagram Protocol (UDP) are also used to transfer data between Beacon targets that allow an Agent to monitor services and the network components you are monitoring. If there is a firewall or ACL between the Web application components and the Beacons you use to monitor those components, you must configure it to allow ICMP, UDP, and HTTP traffic.
When the host where the agent resides is protected by a firewall, you need to configure the agent to use a proxy, or configure the firewall to allow incoming communication from the OMS. To configure the firewall you must determine the port assigned to the agent and whether communication is HTTP or HTPS. You can find this information by running emctl status agent.
To configure the proxy set the following properties using the Enterprise Manager Console to edit the Agent properties or emctl setproperty agent and restart the agent. The proxy realm, user and password may not be required in all environments.
$ emctl setproperty agent -name REPOSITORY_PROXYHOST -value proxy42.acme.com $ emctl setproperty agent -name REPOSITORY_PROXYPORT -value 80 $ emctl setproperty agent -name REPOSITORY_PROXYREALM –value <value if needed> $ emctl setproperty agent -name REPOSITORY_PROXYUSER –value <value if needed> $ emctl setproperty agent -name REPOSITORY_PROXYPWD –value <value if needed>
In cases where the Oracle Management Service is behind a firewall, configurations will be needed to allow proxy communications to the agents or incoming communication through the firewall.
If the agents that are behind the firewall are in different domains, you can configure the proxy to allow communication for those agents and use the dontProxyFor parameter to identify the agents within the firewall. To configure the proxy on the Management Service set the following properties using emctl set property. The proxy realm, user and password may not be required in all environments.
$ emctl set property -name REPOSITORY_PROXYHOST -value proxy42.acme.com $ emctl set property -name proxyPort -value 80 $ emctl set property -name dontProxyFor –value “.acme.com, .acme.us.com”
To configure the firewall to allow inbound communication from the agents for metric uploads, the firewall must be configured to accept HTTP/HTTPS traffic on the upload ports. The default ports are 4889 (HTTP) and 1159 (HTTPS). If your ports were customized you'll need to use those ports.
If there is a firewall between your browser and the Enterprise Manager Console, you must configure firewall to allow the console to receive HTTP/HTTPS traffic over port 7788/7799 (defaults). You can validate your port by looking at the URL you access the Console with.
https://mgmthost.acme.com:7799/em
Additional component installations such as JVMD, APD and BI have additional port requirements. For example, if BI Publisher is installed additional ports may be needed for access to the reporting console. Default ports are 9702/9703 (http/https). For more information please see the documentation specific to the component.
To manage the database targets that are configured behind firewalls, you must allow Oracle Net traffic on the listener ports (typically 1521 but often customized). For more information regarding configuring Oracle Databases for firewalls see the Oracle Database 2 Day + Security Guide.
It is recommended to configure OMS and Agents to support only TLS v1 protocol, which is the successor of SSL v3, for the communication. By default the OMS is configured in mixed-mode, accepting both SSLv3 and TLSv1 protocols.
To configure OMS for TLS v1 protocol only:
$ emctl stop oms
$ emctl secure oms -protocol TLSv1
Append the following to the JAVA_OPTIONS in Domain_Home/bin/startEMServer.sh. If this property already exists, update the value to TLS1
-Dweblogic.security.SSL.protocolVersion=TLS1
$ emctl start oms
To configure an Agent to support only TLS v1 protocol while the Agent listens as a server, edit the Agent properties in the Enterprise Manager Console or use emctl setproperty at the command line. To edit multiple Agents at a time, go to Setup -> Agents, select the Agents you want to modify, click Properties. This will create a job and you can specify the Agent property changes on the Parameters page that will get applied to all selected Agents. To use the command line, issue the following:
$ emctl setproperty agent -name allowTLSOnly -value true
The Oracle Management Service and Oracle Management Agents can run in non-secure (HTTP) or secure (HTTPS) modes. The recommendation is to always use secure mode, hence the default installation will automatically secure-lock the OMS. The secure-lock mode takes security one step further in requiring that agents communicate only through HTTPS port (HTTP port is locked). This ensures that the OMS-Agent communication is always encrypted and mutually authenticated. All requests from un-secure agents are rejected by the OMS. Similarly, any un-secure request from the OMS is rejected by the agent. This helps safe-guard the management system from any malicious 'man-in-the-middle' attack happening from within the infrastructure.
If your installation was done before Oracle Enterprise Manager 10g Release 5, you may be required to secure-lock your OMS manually. In the case of upgrades, if the pre-upgrade environment is secured, the upgrade retains the secure mode but does not secure-lock the OMS. If the pre-upgrade environment is already secure-locked, the upgrade retains the secure-lock mode between OMS and Agent.
To check the secure status of the OMS and secure-lock the communication between OMS and agent run the command and restart the OMS:
$ emctl status oms –details Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Enter Enterprise Manager Root (SYSMAN) Password : Console Server Host : mgmthost.acme.com HTTP Console Port : 7790 HTTPS Console Port : 7803 HTTP Upload Port : 4890 HTTPS Upload Port : 4904 OMS is not configured with SLB or virtual hostname Agent Upload is locked. OMS Console is locked. Active CA ID: 1 Console URL: https://mgmthost.acme.com:7803/em Upload URL: https://mgmthost.acme.com:4904/empbs/upload … $ emctl secure lock –upload Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Enter Enterprise Manager Root (SYSMAN) Password : Agent Upload is locked. Agents must be secure and upload over HTTPS port. Restart OMS.
Note that once OMSs are running in secure-lock mode, unsecure agents will not able to upload any data to the OMSs. To check the status and secure the agent issue the following, you will be prompted for the registration password:
$ emctl status agent –secure Oracle Enterprise Manager 12c Cloud Control 12.1.0.1.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Checking the security status of the Agent at location set in /scratch/cllamas/oracle/em12/agent/agent_inst/sysman/config/emd.properties... Done. Agent is secure at HTTPS Port 3872. Checking the security status of the OMS at https://mgmthost.acme.com:4904/empbs/upload/... Done. OMS is secure on HTTPS Port 4904 $ emctl secure agent Oracle Enterprise Manager 12c Cloud Control 12.1.0.1.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Agent successfully stopped... Done. Securing agent... Started. Enter Agent Registration Password : Agent successfully restarted... Done. EMD gensudoprops completed successfully Securing agent... Successful.
To ensure the console access from the client browser is secure over SSL/TSL, the console must be locked as well. From Oracle Enterprise Manager 10g Release 5 installations are secure-locked by default. In the case of upgrades, if the pre-upgrade environment is not secure-locked, after the upgrade you need to run the following command to secure-lock the console access:
$ emctl secure lock –console
A cipher suite is a combination of cryptographic parameters that define the security algorithms and key sizes used for authentication, key agreement, encryption, and integrity protection. Cipher suites protect the integrity of a communication. For example, the cipher suite called RSA_WITH_RC4_128_MD5 uses RSA for key exchange, RC4 with a 128-bit key for bulk encryption, and MD5 for message digest. Enterprise Manager allows strong cipher suites for the communication between OMS and agent. By default, the following cipher suites will be allowed for the communication on the agent:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
To see the current Cipher Suites enabled view the Agent properties in the Enterprise Manager Console or run:
$ emctl getproperty agent -name SSLCipherSuites Oracle Enterprise Manager 12c Release 1 12.1.0.1.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. SSLCipherSuites is unset; default value is SSL_RSA_WITH_RC4_128_MD5:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_DES_CBC_SHA:SSL_RSA_EXPORT_WITH_RC4_40_MD5:SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
To configure the strong cipher suites to be used for agent SSL/TLS communication edit the Agent properties in the Enterprise Manager Console or use the setproperty command:
$ emctl setproperty agent -name SSLCipherSuites -value <values>
The following are supported strong cipher suites:
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_DH_anon_WITH_3DEC_EDE_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
To restrict the strong cipher suites used by OMS, please edit SSLCipherSuite parameter in $INSTANCE_HOME/WebTierIH1/config/OHS/ohs1/httpd_em.conf and ssl.conf files with the appropriate values. Here are the default values:
„h SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
Use a certificate from well-known Certificate Authority (CA) to secure OMS-Agent communication and console access to take advantage of the well-known trusted certificates with different expiry and key size. Please refer to the section Configuring Secure Communications in Oracle Enterprise Manager Cloud Control Security Guide for detailed information.
Oracle has introduced the concept of a wallet, which is a password-protected container used to store authentication and signing credentials, including private keys, certificates, and trusted certificates needed by SSL.
To secure the console using a custom certificate authority, you need to create a wallet location and secure the console against that wallet location. For more information on creating a wallet, see Oracle Fusion Middleware Administrator's Guide.
Best Practices for Securing Communication
• Enable ICMP for ping check validation
• Configure firewalls as appropriate in your environment
• Secure and lock the OMS and Agents
• Configure strong cipher suites for the OMS and Agent
• Secure upload and console virtual HTTPS hosts with third party certificates
Enterprise Manager Cloud Control 12c offers multiple methods of authentication. In addition to the predefined methods, a customized provider/module can be plugged in to Cloud Control authentication. The default system authentication method is the standard Repository based authentication. Additional predefined methods include:
Oracle Single Sign-On (OSSO)
Enterprise User Security (EUS)
Integration with Oracle Access Manager Single Sign-On (OAM SSO)
Direct LDAP integration (Oracle Internet Directory, Microsoft Active Directory)
Refer to "Configuring Authentication" for detailed information about how to configure Enterprise Manager to use the pre-defined providers.
Using one of the extended authentication modules enables you to take advantage of centralized identity management across the enterprise. Doing this allows you to rely on the external identity management system for password security compliance, password changes and resets. To create a user in Enterprise Manager with external authentication, you select the “external” flag upon creation. During creation of every new user in Enterprise Manager you are prompted for that users mode of Authentication, via an external Identity store such as Oracle Access Manager(OAM), LDAP or Oracle Internet Directory(OID), or internally via Enterprise Manager Repository. The following figure shows the default window which appears during user creation.
When the account is deleted from the identity management system, it will no longer authenticate in Enterprise Manager but still needs to be manually removed. Ideally, a script or job could be run to remove the user from Enterprise Manager once removed from the identity management system.
When using external Authentication, Enterprise Manager allows the creation of external roles which map to the identity management systems groups by name (i.e. Enterprise Manager role “DBA” maps to LDAP group “DBA”). Thus allowing synchronized user access and privileges based on external group membership.
Target authentication provides access to the host, database or application targets managed through Enterprise Manager. Using strong target authentication methods, named credentials and configuring database password profiles are a few ways to ensure secure target authentication.
To ensure target authentication security, choose strong host and database authentication methods. Credentials for target access are encrypted and stored in Enterprise Manager. With Enterprise Manager Cloud Control 12c, strong authentication such as SSH-keys for host and Kerberos tickets for database are now supported. These credentials can be used by jobs, deployment procedures and other subsystems.
Best Practices for Authentication
Integrate with corporate identity management system for enterprise wide authentication
Use external roles to automatically assign privileges to users based on external group membership
Automate user creation/deletion based on external group membership using EMCLI
Utilize strong authentication methods (SSH for host, Kerberos for database)
For local accounts set up password policies
Authorization is the act of validating the privileges and permissions of an authenticated subject. To avoid exploiting authorization, you must implement a policy of segregation of duties. This means no one person should be given responsibility for more than one related function.
Enterprise Manager users may vary widely among a company, and they may have very different roles and purposes.
Enterprise Manager 12c comes with several out-of-the-box roles that provide role based authentication for various operational roles. Segregation of Operator, Designer and Administrator functions for Patching, Provisioning, Cloud, Compliance, and Plug-ins allow more granular authentication for users. Use the Create Like feature to further enhance or restrict as required for your operations. With using Role Based Access Control (RBAC), privilege management becomes easier; managing role grants is simpler than managing privilege grants. For a complete list of the out-of-the-box roles see the Privileges and Roles section of the Oracle Enterprise Manager Cloud Control Administrator's Guide.
With Enterprise Manager 12c we have the ability to specify target privileges and resource privileges. Target privileges allow an administrator to perform operations on a target. Some of the new target privileges include Connect to any Viewable Target, Execute Command Anywhere, Execute Command as any Agent and more. The target privileges can be assigned for all targets or for specific targets. Resource privileges grant access to a function, button or page within Enterprise Manager. Some of the new resource privileges include Backup Configurations, Cloud Policy, Compliance Framework, Enterprise Manager Plug-in, Job System, Patch Plan, Self Update and Template Collection. For a complete list, see "Configuring Privileges and Role Authorization". With these new privileges, it's much easier to implement the Principal of Least Privilege by creating specific roles with very fine grained privileges assigned that match the job duties.
An extended auditing system makes it easy to monitor the privilege grants on a regular basis and also keep track of which users exercised what privileges. Some of the key privilege related auditable actions are listed here:
Grant job privilege
Grant privilege
Grant role
Grant target privilege
Grant system privilege
Revoke job privilege
Revoke privilege
Revoke role
Revoke target privilege
Revoke system privilege
Super Administrators have FULL privileges on targets/reports/templates/jobs. These are the only users who can create other users and Super Administrators, and grant/revoke privileges to/from other users. Super Administrator privilege should be granted with caution. Using the following query to get the list of Super Administrators:
SELECT grantee FROM MGMT_PRIV_GRANTS WHERE PRIV_NAME = 'SUPER_USER'
Best Practices for Privilege and Role Management
Create meaningful roles and grant roles to users instead of granting privileges to users.
Grant only the minimum set of privileges a user needs for carrying out his/her responsibilities by granting the fine-grained privileges/roles only when needed.
Audit privilege and role actions for complete monitoring and accountability.
Limit the number of Super Administrators
The fine granularity of privileges provided in Enterprise Manager allows for the Principle of Least Privileges to be implemented, this recommends that an Administrator must only be able to access the information or resources that are necessary for legitimate purposes.
Using groups and systems to organize your targets helps reduce security administration overhead. There are two types of groups available in Enterprise Manager 12c that help simplify privilege management and authorization. By granting roles to groups, instead of users and using privilege propagating groups, you can reduce the direct grants and ensure users have access to the targets as needed.
Privilege Propagating Groups simplify the privilege assignment, revocation, and administration along with group management by propagating the assigned privileges to all members of the group. For example, a user can be granted access to a privilege propagating group Sales, and they in turn receive access to all targets within that group.
Administration Groups are privilege propagating groups that automate the application of monitoring settings to targets upon joining the group. Targets cannot be assigned directly to the group, rather they are automatically added based on membership criteria.
Systems are also privilege propagating and allow you to group all related targets of a particular application or function into a system.
Best Practices for Groups and Systems
Create meaningful roles and grant roles to users instead of granting privileges to users.
Grant only the minimum set of privileges a user needs for carrying out his/her responsibilities by granting the fine-grained privileges/roles only when needed.
Utilize privilege propagating groups and systems to reduce administration overhead
Enterprise Manager has additional auditing that is available for purposes of tracking and validating infrastructure actions performed in Enterprise Manager, including jobs and credentials accessed. Basic and infrastructure auditing is enabled by default for Enterprise Manager 12c.
To enable audit for a subset of audited operations, please use the following EMCLI verb:
$ emcli update_audit_settings -audit_switch="ENABLE/DISABLE" -operations_to_enable="name of the operations to enable,for all operations use ALL" -operations_to_disable="name of the operations to disable, for all operations use ALL"
For example to audit only logon/logoff you would issue:
$ emcli update_audit_settings –audit_switch=”ENABLE” –operations_to_enable=”LOGIN;LOGOUT”
Refer to the section "Configuring and Managing Audit" for the list of operations that are audited by Enterprise Manager.
In Enterprise Manager 12c, there are over 150 options for auditing. The following command will show you the list of operations that can be audited by Enterprise Manager:
$ emcli show_operations_list
The following example shows the output of this command.
$ ./emcli show_operations_list Operation ID Operation Name Infrastructure Operation ADD_AGENT_REGISTRATION_PASSWORD Add Registration Password NO ADD_CS_TARGET_ASSOC Add Standard-Target Association NO AGENT_REGISTRATION_PASSWORD_USAGE Registration Password Usage NO AGENT_RESYNC Resync Agent NO AG_AUD_CREATE Create Administration Groups NO AG_AUD_DELETE Delete Administration Groups NO AG_AUD_MODIFY Modify Administration Groups NO APPLY_TEMPLATE Apply Monitoring Template NO APPLY_UPDATE Apply Update YES ATTACH_MEXT Attach Metric Extension NO
Once audit is enabled, the audit records are kept in MGMT$AUDIT_LOG view in the Repository. Use Enterprise Manager Cloud Control Console to monitor the audit data as user with Super Administrator, click Setup -> Security -> Audit Data.
The externalization service via EMCLI verb update_audit_settings externalizes the audit data from the Repository to an external file system on a regular basis. Make sure there is enough space in the directory for the audit log files.
$ emcli update_audit_settings -file_prefix=<file_prefix> -directory_name=<directory_name> -file_size = <file size> -data_retention_period=<period in days>
The following example shows that the audit data will be retained in the Repository for 14 days and once exported the data will be stored in the OS directory that corresponds to database directory AUDIT with filenames prefixed with gc12_audit, and the file size will be 50M bytes each:
$ emcli update_audit_settings -externalization_switch=ENABLE -file_prefix=gc12_audit -directory=AUDIT -file_size=50000000 -data_retention_period=14
Achieve separation of duties by restricting the access to the directory where the externalized audit data is stored. No Enterprise Manager users should have access to the externalized audit data.
Formalize the audit process by setting up an Audit Review schedule or integrating with an Audit tool such as Audit Vault for notifications and alerts.
Externalize the audit service and secure the files created
Preferred Credentials simplify access to managed targets by storing target login credentials in the Management Repository. Users can access an Enterprise Manager target that recognizes those credentials without being prompted to log into the target. Preferred credentials are set on a per user basis, thus ensuring the security of the managed enterprise environment. Default credentials can be set for a particular target type as well as target credentials for a particular target. The target credentials override the default credentials.
Do not set preferred credentials for group/common accounts such as SYSMAN. If preferred credentials are set for common accounts, then the accountability of the use of these credentials is lost. The following SQL statements can be used to report the list of users who have the preferred credentials set:
SELECT t.target_name,tc.user_name,tc.credential_set_name FROM MGMT_TARGET_CREDENTIALS tc, MGMT_TARGETS t WHERE tc.target_guid=t.target_guid SELECT t.target_name,tc.user_name, tc.set_name FROM EM_TARGET_CREDS tc, MGMT_TARGETS t WHERE tc.target_guid=t.target_guid and tc.user_name = 'SYSMAN'
Credentials can be stored as Named Credentials and then privileges granted to other users to use, update or own the credentials. These credentials can be used for jobs, patching or other administration tasks on specific targets or globally. Eligible credential types include username/password, SSH-key for host and Kerberos for database. This method allows administrators to configure Named Credentials for privileged access and grant to specific users. Auditing tracks Named Credential creation, modification and usage.
Named Credentials provide a secure mechanism in Enterprise Manager to allow for separation of privilege management from privilege delegation for targets. Using Named Credentials an organization can separate the management of the specific username/password/authentication details from the actual authority to use these credentials. This is an essential tool in modern, secure organizations where there needs to be certainty that a malicious user cannot conduct operations outside Enterprise Manager using a set of known credentials obtained from inside Cloud Control. Additionally, the management of a central set of Named Credentials removes a significant burden on the proliferation of credentials information across many Enterprise Manager administrators and also therefore reduces the likelihood of these being used outside the Enterprise Manager environment or helps prevent against the accidental publication of credentials.
Best Practices for Credentials
Use EMCLI to automate routine password changes on privileged named credentials, this allows one administrator to know and update the password for granted users.
Utilize named credentials when setting preferred credentials to simplify credential management.
Do not set preferred credentials for group/common accounts such as SYSMAN.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
